Auth0の製品ライフサイクルについてまとめてみた #Auth0JP #Auth0アドカレ

Auth0の機能を顧客に提供するまでの流れを確認し、Auth0を使ってサービスを提供する側は何をすれば良いのかを知りたい。

公式ドキュメントを読み、簡単にまとめていきます。

Auth0構築時の目標

• フィードバックに基づいて繰り返し、顧客に早期かつ頻繁に価値を提供
• お客様の深い理解を求め、すべての決定においてそれらを考慮
• より良い選択を行うため、執拗にデータを取得して分析する
• 機能を追加するときに、製品全体の現在、理想化、および将来のバージョンを視覚化して設計

上記の目標を達成するため、反復的なアプローチを実施して新機能の導入と改善を可能にする。

機能リリース、機能廃止の流れ

Early access -> Beta -> GA -> Deprecation -> End といった流れとなっています。

Early access

お客様と開発パートナーに、将来の機能オプションをテストしてフィードバックを提供する機会を提供するフェーズ。

機能が意図した目標と一致していることを確認、ソリューションが実際に使用可能であることを検証、提案された改善案を引き出す　といったことを参加者と行います。

限られた数の選択された加入者のみが利用できるプライベートプレビューで、得られたフィードバックはその後のGAや製品リリースに役立つことがほとんどです。

Beta

GA前の最終的なフィードバック機会、顧客に新製品の機能を調査して採用する時間を提供するフェーズ。

※ Beta版には、選択した数のサブスクライバー（プライベート）に制限される場合と、すべてのサブスクライバーに公開される（パブリック）場合があります。

Beta版は機能としてほぼ完成していますが、本番環境での使用はまだサポートされていません。 開発環境やステージング環境で利用するようにしましょう。

重要な変更が行われる場合もありますが、その際は早めに連絡が行われます。

ここでのフィードバックは、後続のリリースでの改善と修正の優先順位付けに役立つことがほとんどです。

GA

完全に機能し、すべての顧客が本番環境で使用できるフェーズ。

※ 購入しているサブスクリプションによっては使えないものもあります

新しいリリースが既存の機能に置き換わる場合は、非推奨ポリシーに従って下位互換性の期間を提供し、 新しいリリースを採用する時間を確保できるようにお客様に通知されます。

※ APIのバージョン変更などがありますね

Deprecation

非推奨の機能で、新規顧客による使用がサポートされない、積極的に拡張されない、最小限のメンテナンスしか行われないフェーズ。

※ 非推奨時にこの機能を使用しているテナントは、引き続きアクセスできます

非推奨の機能が終了するまでの間に、非推奨の機能または動作から離れるために移行を行う必要があります。

移行プロセスが用意されるので、それに従いましょう。

壊滅的な変更やAuth0の使用方法の変更があった場合には、積極的に顧客に通知され、可能な場合には、移行や代替機能のための推奨事項を添えて、 使用済みの通知が提供されます。

End

Auth0プラットフォームから削除されるフェーズ。

継続して使用すると、エラーが発生する可能性があります。

移行プロセスについて

非推奨の機能が通知された後、利用者は移行を行う必要があります。

サポート終了のお知らせを受け取る -> 移行ウィンドウの期間に準備 -> 移行ウィンドウの期間に移行ガイドに従って移行を行う　といった流れになります。

非推奨が発表されるときは、プラットフォームから削除される日付が含まれるか、機能をすぐに廃止し、後でサポート終了日を決定する場合があります。

※ サポート終了日は、プランの種類によって異なる場合がある

通常、サポート終了の発表からサポート終了日までに少なくとも6か月の移行期間が設けられています。

重大な脆弱性など、緊急に対処しないといけないような時はこの期間が短縮されますが、出来る限り事前に通知されます。

実際の移行には移行ガイドが公開されますので、それに習って移行していきます。

移行ガイドには、アプリケーションのコードに必要な変更の詳細、その他の必要なアクションの通知、オプトインの方法が記載されています

サポート終了日に達すると、移行ウィンドウ中にオプトインしなかったテナントに対して、新しい動作が自動的に有効になります。

最後に

Auth0の製品ライフサイクルに関してまとめてみました。

できるだけ早く顧客に価値を提供するためにどんどんと開発サイクルを回す、通知をしっかり行う　といったことは自身でサービス提供している側でもとても参考になると思いました。

SaaS利用者側もせっかく与えられたフィードバックの機会を無視せず、積極的に利用しないといけないなと感じます。 そして、重要な情報が含まれる通知を見逃さないようにしないといけませんね（メールだけでなくSlackにも流すようにしたりだとか）。

参考

• ベータサービス規約

• 非推奨と移行